Many administrative
tasks must be completed on a daily basis, some are needed only
occasionally, and then there are those few that are rarely required.
Windows PowerShell can help with all of these types of tasks; in fact,
you may discover that it is more critical to script a rarely executed
task than one you perform every day. This may be because you need to
execute that rare task quickly and correctly, because the ramifications
of making even a small mistake while completing the task could be
catastrophic. Throughout this book, you will see many examples of when
and how to use Windows PowerShell. In the following sections, you
explore a few examples that you may not have seen elsewhere.
Note:
SEE ALSO There is a section of the Microsoft Script Center, http://gallery.technet.microsoft.com/ScriptCenter/en-us, that contains SharePoint-related scripts.
1. Deploying SharePoint 2010 with Windows PowerShell Scripts
During the lifetime of your SharePoint installation,
there may be many tasks that you must complete (hopefully) only once,
such as installing SharePoint and creating your farm. In large
organizations with a variety of environments and many developers to
support, however, you may find it prudent to develop scripts right from
the outset that will build your SharePoint Web front-end (WFE) servers
and your SharePoint applications servers, which host your applications
services, such as InfoPath Services and search query and indexing
services. In previous versions of SharePoint, you could complete such
tasks using batch files and the SharePoint command-line tools psconfig
and stsadm. You can still use these tools to automate the installation of your SharePoint 2010 and SharePoint Foundation 2010 servers.The order of these commands and
parameters can be quite tricky, so Microsoft recommends that you use
the Windows PowerShell module, SPModule, documented in the Microsoft’s
TechNet library article, “Install SharePoint Server 2010 by using
Windows PowerShell”, at http://technet.microsoft.com/en-us/library/cc262839.aspx.
Note:
MORE INFO For information about SharePoint automation and the use of psconfig, stsadm, and Windows PowerShell, see http://stsadm.blogspot.com/.
When you work on a SharePoint installation, you will need to merge the logs. The Windows operating systems provide you with event logs to help you with your administrative tasks, and you can use the Windows PowerShell Get-Eventlog cmdlet to obtain detailed information from those logs. SharePoint also provides the Unified
Logging Service (ULS). The ULS contains all application log events, and
third-party logging software can be integrated into them as well.
SharePoint 2010 includes several Windows PowerShell cmdlets for
retrieving information and configuring the ULS. To find how ULS is
configured on your farm, type the following command. (The sample output
for this command is also shown here.)
Get-SPDiagnosticConfig
AllowLegacyTraceProviders : False
CustomerExperienceImprovementProgramEnabled : True
ErrorReportingEnabled : True
ErrorReportingAutomaticUploadEnabled : True
DownloadErrorReportingUpdatesEnabled : True
DaysToKeepLogs : 14
LogMaxDiskSpaceUsageEnabled : True
LogDiskSpaceUsageGB : 3
LogLocation : %CommonProgramFiles%\Microsoft Sh
ared\Web Server Extensions\14\LOG
S\
LogCutInterval : 30
EventLogFloodProtectionEnabled : True
EventLogFloodProtectionThreshold : 5
EventLogFloodProtectionTriggerPeriod : 2
EventLogFloodProtectionQuietPeriod : 2
EventLogFloodProtectionNotifyInterval : 5
ScriptErrorReportingEnabled : True
ScriptErrorReportingRequireAuth : True
ScriptErrorReportingDelay : 60
When diagnosing a problem, you can use cmdlets associated with
the SPLogEvent object. You need machine administrator privileges to run
these cmdlets, so you may need to start SharePoint 2010 Management
Shell using Run As Administrator. Then you would use commands in steps
similar to those shown in the following example.
Set up two variables to store the start day and the end date, for example.
$SDate = Get-Date -Day 13 -Month 04 -Year 2010
$EDate = Get-Date -Day 14 -Month 04 -Year 2010
Or the date
could be today’s date, but the event occurred approximately 15 minutes
earlier than the current time. In this case, you set the variable to 20
minutes before the current time and 10 minutes before the current time.
$SDate = (Get-Date).AddMinutes(-20)
$EDate = (Get-Date).AddMinutes(-10)
Obtain a list of events between those two dates and times.
Get-SPLogEvent -StartDate $SDate -EndTime $Edate
If the –EndTime parameter is not provided, the event logs will be displayed up until the current date and time.
A tracking number, known as the Correlation ID, is associated with
each request you make to SharePoint. This number is stored as a value
in a property associated with the SPLogEvent object. SQL Profiler
traces also show the Correlation IDs. This number is displayed on an
Error page, as shown in Figure 1.
In a large or heavily used
SharePoint installation, many logs may be produced during the period
when a problem occurs. You can use the Correlation ID to help
troubleshoot errors by reducing the amount of log information that is
returned to those entries that are associated with the incident. Again,
set the $sdate and the $edate
variables to reflect the time around the incident. For an incident that
you can’t reproduce and one of your users always can reproduce, you
might tell the help desk to ask the user to take a screenshot of the
error page so you can be sure to obtain the exact Correlation ID
number. Then you can pipe the results of the command shown in step 2 to the Where-Object cmdlet, as shown in the following example.
PS C:\Users\Peter>Get-SPLogEvent -StartDate $SDate -EndTime $EDate |
where {$_.Correlation -eq "68bc5cf4-5a8c-4517-a879-86e35e57c862"}
The output will display only event logs between the two dates that are related to the problem associated with that Correlation ID.
